From e9af8a2a679c8a7271df3b8d242c67cffcd9842b Mon Sep 17 00:00:00 2001 From: Daniel Boles Date: Sat, 5 Aug 2017 20:21:28 +0100 Subject: [PATCH] AccelLabel: Fix displaying accel unichars >= 0x80 MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit In GTK+ 2, the ch < 0x80 was ORd with klass->latin1_to_char, and that was unconditionally set to TRUE in the class init function, so effectively the ch < 0x80 never mattered before or served any purpose. When klass->latin1_to_char was deleted from the class in commit f760538f17673c5bd7fec792be2f1abf8148fc32, this check’s sense changed. The resuls was that accel keyvals with gunichar value >= 0x80 stopped being rendered as symbols, instead falling back to their keysym name. Instead of recognisable symbols for these, we get raw, often obscure, and untranslatable keysym names. This breaks accessibility as well as client users who may be parsing such accels and migrating from GTK+ 2. So, remove the < 0x80 to restore the behaviour from before said commit. https://bugzilla.gnome.org/show_bug.cgi?id=783906 --- gtk/gtkaccellabel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gtk/gtkaccellabel.c b/gtk/gtkaccellabel.c index 520c2a5967..6b344a63ff 100644 --- a/gtk/gtkaccellabel.c +++ b/gtk/gtkaccellabel.c @@ -816,7 +816,7 @@ _gtk_accel_label_class_get_accelerator_label (GtkAccelLabelClass *klass, } ch = gdk_keyval_to_unicode (accelerator_key); - if (ch && ch < 0x80 && (g_unichar_isgraph (ch) || ch == ' ')) + if (ch && (ch == ' ' || g_unichar_isgraph (ch))) { if (seen_mod) g_string_append (gstring, klass->mod_separator); -- 2.30.2